1. Middleware תרגום - אמצע הדרך - זה נועד לבדיקה עם המשתמש מחובר או לא וכדומה (בדיקה בין הניווט של המשתמש ובין ההגעה לפונקציה בקונטרולר
validate נועד לבדיקת נתונים מטפסים (כמו לדוגמה שהID הוא מספרים)

1,2. בפריימוורקים מסוימים, ביניהם לאראוול, אקספרס, סלים, וסימפוני, מקובל לחשוב על העבודה שהשרת מבצע בתור עיבוד של בקשה לשרת לתשובה ללקוח. הרעיון אומר שמהלקוח מגיעות בקשות. בקשות (מסוג http) כוללות כל מני נתונים, כמו כתובת, כותרים, קוקיז ותוכן של טפסים. תשובות http כוללות כותרים (קוקיז, סטטוס בקשה 404 וכו) ותוכן שיכול להיות ויכול שלא להיות בפורמט html.

הרעיון של הפריימוורקים הללו היא שאתה תכתוב פונקציה (מתודה של מחלקה מסוג קונטרולר) שיודעת לקבל בקשה ולהחזיר על בסיסה תשובה. עבור בקשות לכתובות שונות תכתוב פונקציות שונות ועל בסיס מיפוי כתובות לקונטרולרים הפריימורק יפעיל את הפונקציה המתאימה שלך.

אמנם לפעמים הם מציאים לך קיצורי דרך, כמו ישר לעשות echo מתוך הקונטרולר. במקרים כאלה הפריימורק יוצר לבד תשובה מסוג http, מציב לה כותרים מתאימים, עותף אותה בסטטוס מתאים ומכניס לתוכן שלה את הטקסט שפלטת.

לצורת העבודה הזו יש פאנצ'ר אחד קטן. במקרים מסוימים הוא יוצר כפל קוד.
למשל, אם תרצה לדחוס את הפלט לשימור גודל התעבורה באמצעות gzip, תצטרך להוסיף לסוף כל מתודה שכתבת פעולה כזו.
דוגמה אחרת היא אם תרצה להוסיף בדיקת הזדהות לפעולות מסוימות. במקרה הזה תצטרך להוסיף קוד בדיקת הזדהות בכל מתודה רלוונטית.

כדי למנוע את כפל הקוד הזה נשנה קצת את התמונה.


עכשיו הדחיסה ובדיקת ההזדהות נכתבות רק פעם אחת בפונקציות נפרדות שמתווספות לתזרים.
פונקציות כאלה נקראות middleware, פונקציות אמצע, שנמצאות איפשהו בין לבין על תזרים הבקשה-תשובה.

לתוך הפריימוורק מובנות פונקציות רבות כאלה שאתה לא רואה על התרשים. כמו פונקציה שמקבלת את הבקשה ועל בסיס הכתובת שבה (והמיפוי שהגדרת) מחליטה איזו פונקציה הבאה להפעיל או להחזיר קובץ מתיקיה או להחזיר תשובה מסוג 404. בסוף הזרם נמצאת פונקציה שבודקת האם היו שגיאות כלשהן במערכת ומציגה עמוד 505 וכו'.



5. המטרה של פריימוורק זה לספק לך כלים ופתרונות כדי שלא תצטרך לכתוב אותם לבד. לכן המסכנה היא להשתמש במה שקיים.
אם אתה בכל זאת רוצה להוסיף לזה משהו, בשום פנים ואופן אל תשנה את קוד המקור של הפריימוורק עצמו.
א. זה לא הדרך העדיפה
ב. זה ימנע ממך לעדכן גרסה בעתיד
הדרך העדיפה היא לקרוא את הדוקומנטציה. את רוב המחלקות שצריך אפשרת לרשת או לדרוס או לממש אינטרפייס משלך למה שצריך. פנה לדוקומנטציה לעזרה.

6. עליך להתייחס ל-traits כאל מחלקות רגילות ולמקם אותם בעץ בהתאם. כלומר בשם תיקיות דומה לשם הניימספייס שלהם (בדיוק כפי שהייתה ממקם את הקובץ אילו הייתה זו מחלקה ולא טרייט)

7. this validate משתמש במופע קיים של ולידטור שיש בתוך המחלקה, השני יוצר מופע של ולידטור חדש. אני מניח שאם תציב אותו בתוך this תקבל את אותה התוצאה, אך לא בטוח. תבדוק בקוד המקור.

8. אתה לא חייב. events הם חלק מפטרן תכנות שנקרא observer
job היא מחלקה בסיסית שאתה אמור לירוש, המייצגת הודעה בתור. קונצפט מסובך. תשכח ממנו. לא מיועד לאתרים פשוטים.

9. שגיאות הם בסה"כ מחלקות מסוג אקספשן, מה שאומר שאתה ממקם אותם באותו מקום (לפי שם ניימספייס תואם לשם התיקיה) איפה שהייתה ממקם מחלקות רגילות וטרייטים. אםה אתה מתכוון לשגיאות וולידציה כמו "מה זה, הכתובת שהזנת איננה תקינה" אז זה בולידטורים.
עמוד ריק מופיע לך לפעמים בגלל שבקוד יש גיאות פיענוח (מנוע ה-PHP לא הצליח להבין את הקוד ולכן לא הצליח להפעיל אותו. זה לא קשור ללאראוול. מספיק שלא תשים נקודה פסיק איפשהו.

1. middleware הוא לא "אמצע הדרך" אומנם אם נכניס ל google translate זה אולי מה שנקבל אבל הקוד שאמור להיות ב middleware הוא קוד כללי שיכול לפעול על מספר קונטרולרים במקביל לפניהם או אחריהם למשל אני רוצה שאחרי כל בקשה לבצע exec לתכנית מסוימת -> after middleware. בדיקה של האם המשתמש מחובר -> before middleware.
הסברתי בעבר על איך לבצע בדיקה לפרמטרים מכתובת - ניתוב עם laravel + שימוש בפילטר ה Middleware הוא התחליף של פילטר ב laravel 5.

2.אין יותר מידי מה לחפור אבל כדאי לדעת דברים בסיסים כמו איך לשלוח הדרים,איך לבצע redirect וכו'

3.אני חושב שהתיעוד שיש באתר שלהם הוא מעולה ואני מאוד ממליץ לקרוא בהרחבה גם על service container וגם על provider במידה ויש משהו שלא הבנת אתה מוזמן לשאול.

4.האם אתה יודע מהו facade ? לגבי לכתוב contract משלך אתה תצטרך להסביר מה אתה עושה,בכללי אני חושב שאם אתה כותב interface באפליקציית laravel עדיף אולי לפתח את זה בתור plugin ואז יהיה לך יותר קל להשתמש באותו קוד גם בפרויקטים אחרים.

5.כל עוד הקבצים לא נמצאים בתיקיה vendor אתה יכול להרגיש חופשי לשחק איתם.

6.איפה הייתה כותב אותם ללא laravel ? אתה יכול ליצור תיקיה חדשה בפרויקט ולקרוא לה "traits".

7.אין הבדל.

8.jobs - מאפשר לך ליצור פעולות בצורה אסינכרונית או סינכרונית,למשל שליחת מייל אני מעדיף שתתבצע ברקע מאחר והיא יכולה לקחת כשנייה וחבל שהמשתמש ימתין עד לשליחת המייל בשביל שאני ישלח לו תשובה.

events - ליצור אירועים שקורים באפליקציה - משתמש נרשם,תשלום שבוצע באתר וכו' ואז כאשר אותו אוונט קורא להפעיל קוד מסוים ,אם זה הרשמה לדוגמא אז לשלוח אימייל ברוכים הבאים,אם זה קנייה אז לשלוח קבלה.

9.יש לך בתיקיה app תיקייה שנקראת exceptions שם אמורים להיות כל השגיאות שלך,ויש לך את ה handler שהוא זה שמופעל מתי שיש שגיאה.
לגבי דף לבן אני לא כזה סגור אבל אני משאר שאתה נמצא ב production והטמפלט של ה "oops" חסר או משהו בכל מקרה אתה יכול לבצע דיבאג ולראות מה גרם לכך.

9. קרה לי שהיה לי דף לבן במקום שגיאה
זה אומר שיש שגיאות ב blade
אני לדוגמה שמתי הערה של
{{-- --}} על סוגריים של blade ואז בכלל לא הופיעה שגיאה אלא רק דף לבן

https://www.google.com/search?q=laravel+wight+page#safe=active&q=laravel+white+page

9. אם הקובץ של הלוג גדול מידי הוא לא מציג הערות , כרגע קרה לי

תודה רבה לכם :)
@intval
@Splash
1. הבנתי מאוד מה זה Middleware ואפילו התנסיתי להכין אחד בעצמי, כזה שבודק בכל route באיזה שפה הדפדפן שלי ומשנה את הLang (בנתיים יש רק he וen) ובהתאם גם את הdir בתגית body( גם מותאם רק לhe או ל en). אולי אני אייעל את זה בכך שאבדוק אם הסשן dir קיים ורק אם הוא לא קיים יבצע את כל הפרוצדורה.

2. אני חושב שבנושא הזה אני פשוט אקרא את הדוק' ואנסה לבדוק איך אני מיישם ואיך זה עוזר לי , בלי יותר מדי חפירה.
3. container זה בעצם הפונקציה app() הזו שמכילה כל מיני עזרים וכאלה ? אני לא כל כך הבנתי מה זה ובמה זה עוזר, ואיך ומתי אני אמור להשתמש בזה. אותו דבר גם לproviders. הבנתי שאלו פעולות מסויימות שאפשר לשלוח לביצוע שם, מעין מרכז בקרה כזה(אם הבנתי נכון),אבל אלו פעולות מבצעים שם ? ואיך ?

4. facede הבנתי שזוהי מחלקה נגיד auth שהורשת לה facede ועכשיו אפשר להשתמש בה כסטטית. ככה זה עובד עם auth לדוגמה(אם זה מה שהבנתי). contracts זה בשביל אינטרפייסים, לא יודע אם יצא לי לכתוב כאלה בלארוול, אבל אם יצא איפה לכתוב אותם ? או שבעצם לא יצא לי?

5. לא התכוונתי לשנות את הקוד מקור, בתיקיה vendor אני נוגע רק כדי לראות איך הדברים פועלים או אם יש לי משהו קטן שאני רוצה לבדוק מה תלוי במה, ואז אני משנה משהו קטן אבל מיד מחזיר. כל שאר השינויים רק בתיקיות הרגילות. והתכוונתי אם אפשר להחליף את הAuthConroller וכל זה. אבל זה כבר פחות רלוונטי כרגע.

6. את המודלים לארוול שמה בתיקיה app, ואני יצרתי תיקיה Models בתוך app ושיניתי איפה שצריך בהתאם. אז חשבתי אולי ליצור כזו גם לtratis.

7. סבבה הבנתי :)

8. אז job וevents בעצם חופפים ומשתמשים בהם יחד ?

9. כן זה בדרך כלל שגיאות של נקודה או גרשיים, לשגיאות בקוד יש שגיאה מפורטת. ואיך יודעים אם הלוג גדול מדי? ומה עושים במקרה כזה ?

-- ועוד שאלה שיצאה לי בפיתוח
למה Session::put('a','b'); לא עובד, אבל app('session)->set('a','b') כן עובד ? מה ההבדל ? הרי זה אמור לעשות את אותה הפעולה.